home *** CD-ROM | disk | FTP | other *** search
/ Ambrosia Times / AT_1.1_5.3_DOCMaker.sit / The Ambrosia Times 5.1.rsrc / TEXT_138.txt < prev    next >
Encoding:
Text File  |  1998-09-26  |  6.3 KB  |  97 lines
  1.  
  2. Bitwise Operator
  3. by Matt Slot
  4.  
  5.  
  6. Up until this point, the Bitwise Operator column has provided an introduction to writing software on the
  7. MacOS. While this would continue to be a valuable journey, there are 3 important reasons to change the
  8. content: the effort to create and maintain the library is prohibitive, there is enough controversy regarding the
  9. lifetime of the platform, and there are many more topics of general interest to developers.
  10.  
  11. To this end, I'm changing the content of the column to include general topics relating to software
  12. development and maintenance. If you are anxiously interested in learning to program for the MacOS, I'd
  13. strongly recommend that you purchase and read some of the excellent Mac programming primers and visit
  14. the Mac related discussion areas on UseNet and IRC (as described in my first column).
  15.  
  16. On Software Development
  17.  
  18. Now, software development is something that really isn't taught very well in college. Sure, most people take
  19. some courses to learn the necessary languages and algorithms, and get a fair dose of practice on small
  20. homework projects. After about 2 years of this, most are able to implement small and specific programs or
  21. libraries. Unfortunately, most undergraduate CS programs don't prepare them for "real world" projects,
  22. software debugging, and maintenance.
  23.  
  24. "Wait a minute," you say. "I'm a damned good programmer!" And most people for whom programming is
  25. incidental to their job or for whom it is a hobby, indeed are good programmers. But once the project grows
  26. beyond one or two people, the source code spans several projects and libraries, and/or you are targetting for
  27. multiple platforms, it becomes easy to waste time in unnecessary or avoidable situations.
  28.  
  29. Each of the upcoming columns will address a different aspect of software development: design techniques,
  30. project structuring, and tools for writing, debugging, and managing your code. Some of them you may be
  31. familiar with, others you may or may not have heard of in passing. Regardless, the focus will be on filling in
  32. those gaps that even a traditional CS degree will leave you with.
  33.  
  34. Focus, Focus, Focus
  35.  
  36. One way I like to divide the programming community is by the way they approach a programming project.
  37. Some people are able to dive right in and begin writing code and implementing features; others take a studied
  38. approach, so that they can implement the project once, in the most efficient way possible. While there is
  39. nothing wrong with either method, each can be carried to an extreme.
  40.  
  41. The first type of programmer gets off to a fast start, and generates alot of code very quickly. He is able to
  42. dive into 3rd party code and libraries, and make use of them quickly with little fuss. He sketches out the
  43. program structure in broad strokes, making some basic assumptions about the intended design so that the
  44. code can continue to flow.
  45.  
  46. As the project continues to grow, the programmer needs to address issues that were previously postponed.
  47. Early assumptions often become hard coded limitations of the engine. The application is structured
  48. incrementally, and may not be very extensible or even efficient, although it works adequately. Common or
  49. repetitive tasks are often implemented in several locations, so continued development and maintanence
  50. becomes increasingly difficult.
  51.  
  52. Later in the development cycle, user feedback may indicate a change in direction to which the developer must
  53. modify the architecture. Poor design may make portions of the code difficult to extend without significant
  54. retooling, which means redundant work. In effect, such a programmer gets a good start on the project,
  55. which is fine for small or one-off products, but which will only hamper an extended project or large source
  56. base.
  57.  
  58. The second type of programmer (of which I am) spends time planning the project, so that it's implemented
  59. "right" from the beginning. He lays the framework for the project with a flexible infrastructure, handy utility
  60. routines, and extensible handlers. He'd rather spend time preparing for the major tasks than diving in, so
  61. that the code doesn't need to reimplemented from the ground up for later enhancements.
  62.  
  63. The programmer likes to pay attention to the details, and will spend a fair amount of time optimizing what he
  64. sees as the most important parts of the program. Rather than just drop-in third party code or libraries, he
  65. insists on being familiar with the mechanism; he may even reimplement some of the core, or at least wrap his
  66. own handlers around the API.
  67.  
  68. The biggest pitfall these programmers face is procrastinating the coding process too long. They often diddle
  69. with design sheets, utility libraries, or optimizing the core engine, and postpone the more significant portion
  70. of the engine until everything is "just perfect". While infrastructure is important, so is actually getting the
  71. project to work. 
  72.  
  73. While some coders and software engineers fall into the extremes of these stereotypes, most fall somewhere
  74. in between. Despite this, everyone should be wary of falling into either "trap" -- and what that requires is
  75. focus. Coders in the first group must be willing to step back and look at the big picture. Bootstrapping some
  76. functionality is fine, but you should focus on some goals -- keep the code modularized, the APIs clean, and
  77. always leave room for extensibility (reference constants, accessor function, opaque data types).
  78.  
  79. Engineers in the second need to roll up their sleeves early in the process. Writing your plan on paper is fine,
  80. as long as you recognize two things: even the best plans may need to be revised or discarded in the future,
  81. and spending too much time on too little code (no matter how essential it is or how often it's invoked) affects
  82. the whole project. Save the 5% speed gains for version 1.1, and focus on making something functional.
  83. Frameworks and early development versions are much more interesting to demo than a handful of really
  84. optimized blitter functions written in assembler. (Use the "mom test" -- which one would she be more
  85. impressed with?)
  86.  
  87. In the end, it's a matter of not drifting to one extreme or the other, but walking carefully in between. If it
  88. takes weeks to plan and organize the project, it's easy to fall behind schedule while not making observable
  89. progress. If the first pass of code seems to work, but it's not well organized or debugged, then it becomes
  90. difficult to complete and maintain the project.
  91.  
  92. Matt Slot, Bitwise Operator
  93.  
  94.     
  95.  
  96.  
  97.